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Abstract 

A  Transfonnational  Communications  Architecture  (TCA)  has  been  proposed  by 
the  US  government  with  the  goal  of  creating  “an  Internet  in  the  sky.”  This  thesis  presents 
a  framework  which  places  user  requirements  at  the  heart  of  routing  and  topological 
decision-making  within  the  TCA.  It  provides  new  terminology  to  describe  data 
transmissions  and  link  characteristics  and  an  approach  to  fonnulating  cost  functions  to 
better  meet  user  needs.  The  framework  is  intended  to  stimulate  interest  and  focus  efforts 
on  how  to  meet  military  specific  requirements  by  taking  advantage  of  the  TCA’s  diverse 
capabilities  and  topology.  Cost  functions  using  newly-defined  parameters  are  simulated 
and  shown  to  improve  relevant  performance  over  a  traditional  routing  approach. 
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A  FRAMEWORK  FOR  ROUTING  AND  TOPOLOGICAL  DECISION-MAKING 
WITHIN  A  TRANSFORMATIONAL  COMMUNICATIONS  ARCHITECTURE 


I.  Introduction 


Background 

The  U.S.  military  has  always  needed  to  share  information.  That  need  has  not 
diminished  with  advances  in  technology.  Data  links  such  as  Link- 16  met  some  of  the 
information  sharing  requirements,  while  other  new  systems  were  developed  to  meet 
mission  specific  needs.  The  differences  between  many  systems  resulted  in  incompatible 
data  formats  which  required  translation  in  order  to  share  data. 

The  development  of  the  Internet  changed  expectations  of  how  rapidly  information 
can  be  accessed.  These  expectations  were  amplified  as  capabilities  for  transmitting  and 
receiving  data  vastly  improved.  Fiber-optics  brought  high-speed  backbone  connections 
which  are  faster  than  those  that  are  copper-based.  Standards  such  as  the  American 
National  Standard  Institute’s  Fiber  Distributed  Data  Interface  (FDDI)  help  ensure 
compatibility  between  products  from  different  vendors.  Speed  improvements  based  on 
fiber-optic  technology  did  not  transfer  into  airborne  systems  which  used  air,  not  copper 
wires,  as  their  medium  for  passing  data. 

The  U.S.  military  have  fought  in  several  conflicts  where  the  ability  to  rapidly 
access  and  pass  infonnation  was  critical  for  success.  Without  the  proper  infrastructure 
the  connectivity  to  pass  information  could  not  be  achieved.  The  vision  of  connecting  all 
warfighters  grew  into  a  concept  that  called  for  the  integration  of  communications 
systems,  computers,  and  infonnation  management  resources  into  a  global  information 
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grid.  However,  a  radical  transformation  of  military  communications  capabilities  and 
infrastructure  is  required  to  interconnect  U.S.  military  forces  in  the  air,  on  land,  or  at  sea, 
throughout  the  world 

The  Department  of  Defense  conducted  a  Transformational  Communications 
Study  which  concluded  that  the  U.S.  communications  architecture  needs  to  be 
transfonned  in  order  to  meet  future  requirements  (GlobalSecurity.org,  2003).  The  next- 
generation  of  communications  capabilities,  the  Transformational  Communications 
Architecture,  will  be  an  “Internet  in  the  sky”  providing  end-to-end  connectivity  necessary 
to  extend  access  to  the  global  information  grid  to  warfighters  everywhere.  This  new 
architecture  includes  diverse  technologies  which  require  new  approaches  to  routing 
information. 

Problem  Statement 

Routing  algorithms  have  used  various  metrics  for  determining  routes.  Path 
length,  reliability,  delay,  bandwidth,  load,  and  communication  cost  have  all  been  used  as 
routing  metrics,  with  path  length  being  the  most  common  (Cisco  Systems  Inc.,  2002).  In 
a  military  environment,  the  requirements  of  the  warfighter  must  be  considered  to  improve 
the  probability  of  mission  success.  The  metrics  stated  above  do  not  consider  the  diverse 
transmission  technologies  found  within  the  Transfonnational  Communication 
Architecture,  and  are  inadequate  for  addressing  some  important  military-specific 
requirements  such  as  the  need  to  avoid  detection. 
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Research  Objectives 

The  goal  of  this  research  is  to  create  terminology  and  metrics  specific  to 
warfighters’  requirements  as  part  of  a  framework  for  routing  and  topological  decision¬ 
making  within  a  Transfonnational  Communications  Architecture.  There  are  two 
objectives.  The  first  objective  is  to  create  terminology  adequate  for  capturing  the 
communications  requirements  of  military  users.  The  second  objective  is  to  create  a  cost 
function  which  considers  the  topology  of  the  Transformational  Communications 
Architecture  and  elicits  a  network  routing  behavior  consistent  with  identified  user 
requirements. 

Methodology 

This  research  identifies  terminology  required  to  adequately  describe 
communications  requirements  and  incorporates  that  terminology  into  a  cost  function  to 
be  used  in  packet  routing.  A  network  simulation  is  performed  using  routing  paths 
consistent  with  the  new  cost  function,  and  an  analysis  comparing  the  new  routing  method 
to  a  standard  method  shows  the  feasibility  of  this  approach. 

Scope 

The  NS2  discrete  event  network  simulator  is  used  to  route  traffic  originating  and 
tenninating  at  a  set  of  pre-determined  nodes.  Two  cost  function  parameters  are  varied  to 
create  four  scenarios  to  represent  four  classes  of  traffic  which  are  routed  based  on  their 
cost  function  values.  The  same  set  of  source  and  destination  nodes  is  used  in  each  of  the 
scenarios.  The  costs  for  each  class  of  traffic  are  calculated  manually  and  the  NS2  routing 
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table  is  modified  by  changing  simulation  software  code  for  each  of  the  scenarios.  Results 
from  each  of  the  scenarios  are  compared  to  results  obtained  from  routing  based  on 
Dijkstra’s  All-Pairs  algorithm. 


Summary 

The  primary  focus  of  this  research  is  to  identify  new  tenninology  as  parameters  to 
capture  communications  requirements  of  military  users  and  to  use  that  tenninology  to 
effectively  route  infonnation  using  the  Transfonnational  Communications  Architecture. 
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II.  Literature  Review 


The  Need  to  Share  Information 

The  need  to  share  information  has  consistently  been  addressed  in  the  post-action 
analysis  of  every  major  conflict  in  recent  history.  The  sharing  of  a  single  secure  satellite 
communications  channel  by  everyone  ranging  from  commanders  to  tactical  users  during 
the  invasion  of  Grenada  is  one  example  of  how  limited  resources  forced  information  to  be 
shared  (Anno  and  Einspahr,  1988:41).  Following  Operation  Allied  Force  in  Kosovo,  Gen 
John  P.  Jumper  stated  “In  another  shortfall,  our  secure  communications  capabilities  were 
insufficient  and  many  of  our  transmissions  were  made  ‘in  the  clear.’  As  a  result,  sensitive 
information  sometimes  fell  into  enemy  hands.”  (Jumper,  Testimony  to  Congress:  1999) 
Calls  for  systems  which  share  information  more  effectively,  as  well  as  organizations 
willing  to  share  infonnation,  have  been  repeatedly  identified  in  post-war  “lessons 
learned.”  But  before  agreement  can  be  reached  on  what  is  lacking,  a  common  language 
with  specific  terminology  must  be  agreed  upon  to  describe  the  problems  and  formulate 
solutions. 

As  the  demand  for  rapid  access  to  current  information  grows,  new  methods  to 
enable  information  sharing  must  accommodate  the  demand.  Some  of  these  methods 
include  improved  physical  infrastructures;  others  include  new  ways  of  thinking  about 
how  to  get  the  right  infonnation  to  the  right  place  at  the  right  time.  All  methods  will 
need  to  have  a  common  framework  to  enable  meaningful  discussion  and  comparison. 

To  better  understand  where  military  infonnation  sharing  is  going,  it  helps  to 
understand  where  it’s  been  and  where  it  is  currently.  Conflict  and  the  threat  of  conflict 
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has  always  been  a  driving  force  behind  military  developments.  As  the  saying  goes, 
“Necessity  is  the  mother  of  invention.”  The  nation’s  need  for  security  drives 
improvements  in  defense,  including  more  effective  command  and  control  and  better 
access  to  infonnation. 

Development  of  Tactical  Data  Sharing 

Tactical  data  sharing  is  an  integral  part  of  defending  the  nation’s  airspace.  The  air 

defense  mission  requires  timely  information  with  rapid  updates  to  maintain  an  accurate 

estimate  of  the  current  air  battle.  This  “air  picture”  must  have  the  fidelity  to  track 

adversaries,  and  effectively  target  them.  The  volume  of  data  required  to  accomplish  the 

air  defense  mission  exceeds  human  capacity  to  express  with  simple  voice  systems,  so 

data  must  be  shared  using  data  links  which  enable  machine-to-machine  connectivity,  with 

human  intervention  being  the  exception.  In  addition  to  enabling  the  air  picture,  command 

and  control  (C  )  systems  must  provide  timely  infonnation,  enabling  users  to  positively 

affect  the  situation  (Golliday,  1985:779). 

The  Tactical  Digital  Information  Link  (TADIL),  a  data  link  designed  by  the  U.S. 

military,  creates  a  tactical  network  capable  of  disseminating  infonnation  during  conflict. 

The  requirements  for  data  links  were  designed  with  military  conflict  in  mind. 

The  data  link  is  the  electronic  equipment,  including  protocols  and  messages,  that 
pennits  transmission  of  information  in  digital  fonn.  As  a  basic  requirement,  data 
links  must  securely  support  the  maintenance  of  a  high-density  rapidly  changing 
air  picture  in  real  time  in  a  hostile  environment.  Specifically,  data  links  must 
have  sufficient  timeliness,  capacity,  security,  and  survivability  among  other 
requirements.  Furthennore,  data  links  must  have  sufficient  flexibility  for 
interconnection  to  support  interoperability  among  the  units  in  a  tactical  data 
system.  (Golliday,  1985:779) 
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Data  links  share  information  via  point-to-point  connections  between  two  users  or 
netted  connections  between  many  users.  This  can  raise  the  level  of  awareness  at  specific 
locations  or  throughout  an  entire  region.  Historically,  military  data  links  were  designed 
to  work  with  specific  systems  and  do  not  interoperate.  Figure  1  shows  a  data  link 
network  with  airborne  elements  as  well  as  ground  units. 


Figure  1.  A  Data  Link  Network 


Stovepipe  Systems 

Data  links  were  developed  for  specific  requirements,  with  each  data  link  being 
characterized  as  either  tactical,  intelligence  surveillance  reconnaissance  (ISR),  or 
command  and  control  (C  ).  The  similarity  between  links  within  a  given  functional  area  is 
generally  greater  than  that  between  links  from  different  functional  areas.  In  short,  the 
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systems  were  designed  to  work  together  within  their  own  functional  areas,  but  can’t 
directly  pass  data  to  other  functional  areas. 

For  data  to  be  shared  with  all  interested  parties,  there  must  be  at  least  one  system 
capable  of  taking  data  from  one  type  of  data  link  and  translating  it  into  formats  usable  by 
other  data  links.  A  common  data  link  capable  of  translating  various  data  formats  could 
have  a  hub  in  a  hub-spoke  topology,  with  translating  capability  similar  to  a  computer 
network  bridge,  broadcasting  data  from  one  networked  node  to  all  of  the  other  networked 
nodes.  By  placing  the  critical  node  at  the  hub,  the  ability  to  communicate  with  non- 
homogenous  nodes  provides  a  robust  ability  to  access  information  through  an  assortment 
different  links.  The  Airborne  Warning  and  Control  System  (AWACS)  radar  plane  in  is 
an  example  of  a  hub  which  is  linked  to  other  aircraft  and  ground  units  using  different  data 
formats. 

Dissimilarities  between  the  data  format  in  each  system  requires  translation, 
introducing  delays.  In  addition,  maintaining  data  interoperability  is  complicated  by  the 
need  to  synchronize  changes  to  the  data  format  in  any  one  system  with  any  other  systems 
with  which  it  communicates.  In  the  case  of  hubs,  the  ability  to  translate  data  may  be 
temporarily  lost. 

As  an  example,  during  the  1990’s,  an  Air  Weapons  Controller  working  at  an  Air 
Defense  Sector  in  the  U.S.  provided  the  physical  hub.  One  night  a  drug  smuggler 
attempted  to  fly  his  airplane  into  Canada.  The  Royal  Canadian  Mounted  Police  (RCMP) 
had  an  aircraft  following  the  criminal,  but  due  to  the  radio  range  limitations  couldn’t 
communicate  with  it.  They  could,  however,  communicate  with  the  Air  Weapons 
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Controller,  almost  a  thousand  miles  away,  over  a  phone  line;  and  he  had  the  capability  to 
connect  their  phone  call  through  radios  in  the  vicinity  of  the  pursuit.  The  RCMP  aircraft 
followed  the  smuggler  to  his  landing  strip  in  Canada,  and  following  a  brief  escape 
attempt,  captured  him  on  the  ground.  In  his  role  at  the  network  hub,  the  Air  Weapons 
Controller  was  able  to  provide  an  interface  between  two  incompatible  systems  (telephone 
and  radio)  and  make  a  connection  between  two  end  nodes  which  needed  to  share 
information.  Such  human  intervention  isn’t  always  feasible. 

Advances  in  Technology 

Major  changes  in  the  world  often  follow  scientific  breakthroughs  or  advances  in 
technology.  Infonnation  technology  has  experienced  rapid  changes  over  the  past  few 
years. 

Internet. 

The  Internet  changed  the  world,  not  only  by  changing  what  information  can  be 
accessed,  but  by  changing  expectations  of  what  information  can  be  accessed,  and  how 
quickly.  Military  users  also  have  a  greater  demand  for  immediate  access  to  information. 
The  U.S.  Army’s  communications  requirement  was  up  to  10  times  larger  than  the 
available  supply.  Shortfalls  in  supply  are  projected  to  persist  beyond  the  year  2010. 

Since  costly  planned  growth  cannot  keep  up  with  the  demand,  better  bandwidth 
management,  replacement  of  bandwidth-intensive  video  teleconferencing  applications 
with  simple  teleconferencing  plus  whiteboard  applications,  and  elimination  of  excessive 
video  downlinks  from  unmanned  aerial  vehicles  (UAV)  will  help  eliminate  lower-priority 
traffic  (Congressional  Budget  Office,  2003 :xii-xiii). 
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The  so  called  “World  Wide  Web”  of  information  has  become  synonymous  with 
ease-of-use  partly  because  the  protocols  and  interfaces  make  interoperability  a  reality. 
The  Internet’s  complexity  has  been  abstracted  into  simple  “point-and-click”  action  that  is 
easily  learned  and  understood.  The  Internet  Protocol  (IP)  is  widely  accepted  and  is  now 
used  throughout  the  world  as  the  primary  carrier  of  data  infonnation.  This  acceptance 
has  enabled  a  growth  in  interoperability  and  the  interconnection  of  systems  on  a  grand 
scale  (Bergzen,  2000:29). 

Fiber-optics. 

Advances  in  laser  technology  have  greatly  increased  the  amount  of  data  one  fiber 
optic  link  can  carry.  Fibers  have  lower  noise,  hence  can  achieve  a  higher  data  rate. 
Lasers  are  immune  to  the  electromagnetic  interference  wires  are  susceptible  to.  The 
result  is  fewer  retransmissions  due  to  errors. 

Most  importantly,  the  theoretical  limit  for  the  information  carrying  capacity  of 
lasers  is  phenomenal: 

For  the  future,  the  ultimate  potential  of  a  single  mode  fiber  has  been  estimated.  It 

is  about  25,000  Gbs  (25,000,000,000,000  bits  per  second).  At  that  rate  you  could 

transmit  all  the  knowledge  recorded  since  the  beginning  of  time  in  20  seconds. 

(Newton,  2001:395) 

Wireless. 

The  Air  Force  vision  of  future  wireless  communications  networks  includes  both 
free-space  optics  (laser)  and  radio  frequency  communications  capabilities  (Teets,  2002). 
The  vision  increases  communications  capabilities  within  the  Department  of  Defense  and 
intelligence  community  by  a  factor  of  10  through  the  inclusion  of  laser  communications 
in  the  communications  architecture. 
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Even  so,  laser  links  have  problems  as  well.  For  example,  laser  links  through  free- 
space  pose  a  challenge  to  link  maintenance  due  to  weather  conditions  and  pollution. 

New  techniques  which  show  promise  in  overcoming  problems  associated  with 
penetrating  clouds  and  other  adverse  weather  conditions  are  currently  in  development. 
Researchers  have  attained  average  bit  rates  higher  than  conventional  optical  wireless 
links  operating  at  2.5  Gbps.  {The  Next  Wave: 2004) 

Radios. 

Current  tactical  radios  were  developed  to  meet  the  mission-specific  requirements 
of  their  respective  services.  Specialized  requirements  led  to  incompatibility  between 
radios.  The  Joint  Tactical  Radio  System  (JTRS)  program  is  addressing  many  of  the 
interoperability  issues  by  clustering  radios  into  groups  based  on  similar  characteristics. 
Each  cluster  builds  upon  a  common  hardware  baseline  which  is  modular,  scaleable,  and 
backwards-compatible  enabling  growth  of  capabilities,  bandwidth,  and  the  addition  of 
network  routing  capability.  JTRS  radios  will  eventually  serve  as  routers  on  tactical  radio 
networks,  possibly  replacing  the  dedicated  data  links  currently  in  use.  Figure  2  shows  the 
JTRS  components  and  their  relationship.  (JTRS  Joint  Program  Office,  2004) 

The  waveforms  within  the  JTRS  are  software  versions  of  radio  waveforms  used 
by  legacy  systems.  These  waveforms  provide  backwards-compatibility.  The  wideband 
networking  waveform  is  a  new  waveform  designed  to  meet  emerging  communication 
requirements  such  as  networking,  secure  communication,  and  higher  capacity.  Minimal 
network  services  provide  the  means  for  digital  information  exchanges.  Together,  these 
three  components  fonn  the  core  framework  of  a  JTRS  radio  set.  The  programmable  radio 
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hardware  utilizes  the  core  framework  to  provide  the  capability  to  communicate — 
transmit,  receive,  bridge,  and  gateway — using  different  waveforms  and  protocols. 


Wideband 

Minimal 

Waveforms 

Networking 

Network 

Waveform 

Services 

Core  Framework 

Programmable  Radio  Hardware 


Figure  2.  Components  of  the  Joint  Tactical  Radio  Set  (JTRS  JPO,  2004) 

Routing 

Once  a  node  has  multiple  links,  it  must  have  a  way  to  detennine  what  information 
should  go  to  which  link.  Putting  routers  into  tactical  radios  to  create  networks  can  be 
complex  and  requires  a  basic  understanding  of  the  differences  between  the  different  types 
of  networks  being  considered.  Regardless  of  the  medium  used  to  transfer  information 
from  a  source  node  to  a  destination  node,  at  some  point  a  decision  must  be  made  about 
how  the  information  must  be  forwarded.  An  important  routing  factor  is  the  topology  of 
the  network  in  question. 

Fixed  Topology. 

In  a  fixed  network  links  between  nodes  are  static.  At  times,  a  route  may  be 
unavailable  due  to  link  failure,  but  a  given  route  will  always  lead  to  the  same  destination 
until  the  topology  is  reconfigured.  By  representing  the  network  as  a  graph,  a  hierarchical 
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addressing  system  may  be  imposed  on  the  topology,  and  create  a  logical  representation  of 
the  network  (Peterson  and  Davie,  2003:271-299). 

With  hierarchical  addressing,  very  large  networks  may  be  supported  because 
network  routers  only  need  detailed  information  about  destinations  in  their  immediate 
vicinity.  However,  it  is  difficult  to  change  a  hierarchical  addressing  scheme  once  it  has 
been  established.  Consequently,  a  hierarchical  addressing  scheme  may  not  be  the  best 
choice  when  the  network  topology  changes  frequently  (Comer,  2000:154).  Furthermore, 
the  military  environment  requires  dynamic  topologies. 

Dynamic  Topology. 

All  networks  have  periods  when  links  are  unavailable,  and  traffic  must  be  routed 
over  alternate  paths  to  reach  its  intended  destination.  Simply  having  links  go  down  and 
come  back  up  creates  a  dynamic  topology.  In  this  context,  however,  a  dynamic  topology 
is  one  where  a  link  may  be  removed  and  a  different  link  may  be  added.  The  network 
graphs  before  and  after  the  link  change  are  structurally  different.  The  implication  is  that 
the  topology  is  changed  to  achieve  better  perfonnance,  connectivity,  or  another  desired 
effect. 

Another  way  for  a  topology  to  be  dynamic  is  for  nodes  to  join  or  depart  the 
network.  A  joining  node  will  create  at  least  one  new  link  which  didn’t  already  exist,  and 
a  departing  node  will  remove  at  least  one  existing  link.  Keeping  track  of  which  nodes 
have  joined,  which  nodes  have  departed,  and  which  nodes  are  linked  at  a  particular  point 
in  time  can  be  complicated  because  new  changes  are  occurring  even  as  the  previous 
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changes  are  being  recorded.  Wireless  networks  must  deal  with  the  very  issues  discussed 
above. 

In  a  network  where  all  nodes  are  mobile,  wireless,  and  have  omnidirectional 
transceivers,  some  nodes  will  be  within  communication  range  of  each  other  and  some 
will  not.  It  may  be  beneficial  for  nodes  within  range  to  maintain  a  listing  of  whom  they 
can  communicate  with,  most  likely  their  nearest  physical  neighbors.  As  information 
intended  for  a  downstream  node  arrives,  it  must  be  forwarded  to  neighbors  who  will 
attempt  to  get  the  information  closer  to  its  intended  destination. 

If  there  is  no  centrally  controlled  entity  which  is  tracking  all  nodes,  there  will  be 
no  global  knowledge  of  where  all  nodes  in  the  network  are  located  at  an  arbitrary  time. 
Without  knowledge  of  the  complete  path  to  a  destination,  each  node  will  transmit 
information  to  its  immediate  neighbors  who  will  repeat  the  transmission  until  the 
information  “ripples”  through  the  network  to  its  intended  destination  node.  Since  every 
node  shares  the  communications  medium  with  its  immediate  neighbors,  each 
transmission  from  one  node  will  result  in  repeated  transmissions  from  each  of  the 
surrounding  nodes.  This  will  tie  up  the  communications  channel  for  all  nodes  in  the 
immediate  vicinity,  even  though  many  of  them  have  already  heard  and  retransmitted  the 
message.  As  the  number  of  nodes  grows,  these  retransmissions  will  tie  up  the 
communications  channel,  resulting  in  a  lower  throughput  for  each  node.  “Some 
implications  may  be  worth  considering  by  designers.  Since  the  throughput  furnished  to 
each  user  diminishes  to  zero  as  the  number  of  users  is  increased,  perhaps  networks 
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connecting  smaller  numbers  of  users,  or  featuring  connections  mostly  with  nearby 
neighbors,  may  be  more  likely  to  be  (sic)  find  acceptance.”  (Gupta  and  Kumar,  2000:2) 

Given  these  findings,  wireless  networks  where  the  links  are  unidirectional  should 
be  considered. 

Recon figur able  Topology. 

A  reconfigurable  topology  is  a  specific  type  of  dynamic  topology  where 
directionality  of  the  links  allows  the  specification  of  which  pairs  of  nodes  are  connected. 
The  intent  is  to  deliberately  control  the  topology  to  cause  a  desired  effect. 

Most  topologies  have  one  existing  link  between  any  two  nodes,  although  it  is 
possible  to  have  multiple  links.  For  example,  two  nodes  may  be  connected  by  a  wire  and 
also  by  a  laser  link.  The  laser  may  be  the  default  method  of  transmission,  but  the  wire 
link  could  be  used  when  electromagnetic  interference  was  low  and  not  degrading  the 
transmitted  signal  noticeably.  Both  could  be  used  simultaneously  to  take  advantage  of  all 
of  the  available  bandwidth.  While  having  more  than  one  link  between  two  nodes  is 
flexible,  it  can  add  to  the  complexity  of  representation  within  a  routing  table. 

A  reconfigurable  topology  where  nodes  join  and  depart  the  network  poses 
challenges  in  keeping  track  of  what  paths  are  available  at  any  given  time.  One  approach 
is  to  store  the  end-to-end  path  information  at  each  node  and  then  update  it  when  it 
changed.  If  the  number  of  nodes  in  a  network  is  small  enough,  end-to-end  routes  could 
be  stored  for  every  node.  Each  node  could  communicate  with  its  neighbors  to  build  a 
connectivity  graph  for  the  entire  network.  As  the  topology  changed,  or  was  altered,  the 
graph  would  be  updated.  This  approach  does  not  scale.  To  alleviate  some  of  the  scaling 
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problems  associated  with  large  networks,  a  hierarchical  topology  and  the  Border  Gateway 
Protocol  (BGP)  may  be  employed  (Perlman,  2000:434).  BGP  indicates  whether  or  not  a 
destination  is  reachable — it  does  not  guarantee  an  optimal  route  even  if  the  destination  is 
reachable.  The  fact  that  a  destination  is  reachable  does  not  provide  a  metric  which  can  be 
used  to  assign  a  cost  to  each  every  route  to  a  destination.  Most  other  routing  protocols 
assign  an  integer  cost,  such  as  hop  count  (Perlman,  2000:439). 

Well-known  approaches  to  routing  in  dynamic  networks  don’t  attempt  to  store 
end-to-end  routing  infonnation  for  all  destinations  at  every  node.  In  Dynamic  Source 
Routing  (DSR),  for  example,  source  nodes  maintain  a  tree  reflecting  known  routes  which 
are  discovered  using  a  route  request  packet  and  are  maintained  using  packet  updates. 

Each  route  is  deleted  after  a  set  expiration  time  and  must  be  rediscovered.  Ad-hoc  On- 
Demand  Distance  Vector  Routing  (AODV)  uses  routing  information  stored  at 
intennediate  nodes.  Source  nodes  still  initiate  path  discovery  with  a  request  packet,  but 
intennediate  nodes  store  the  required  routing  information  when  the  destination  node 
responds.  Like  DSR,  routes  in  AODV  may  also  be  maintained  using  packet  updates. 
Unlike  DSR,  AODV  uses  various  timers  to  denote  the  expiration  of  forward,  reverse,  and 
active  paths  to  the  destination  node  (Pisai,  2001). 

Given  the  dynamic  and  recon  figurablc  nature  of  the  network  under  discussion,  a 
new  approach  to  assigning  cost  is  needed  to  prioritize  the  use  of  the  bandwidth  available. 

Decision  Making  and  Information  Representation 

The  ability  to  make  decisions  is  tied  to  the  meaning  assigned  to  different 
outcomes.  There  are  well-documented  approaches  to  decision  making  when  there  are 
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uncertain  factors  affecting  the  outcome  or  when  there  are  multiple  attributes  affected  by 
each  action  (Winston,  1994:771-778).  The  operational  sciences  deal  with  decision 
making  and  optimization  problems  where  weights  are  assigned  to  attributes  based  on 
their  importance  and  solutions  which  maximize  or  minimize  some  objective  function  are 
found. 

Cost  and  Value  Functions. 

When  all  attributes  affecting  a  decision  are  known,  it  is  possible  to  assign  either  a 
cost  or  a  value  to  each  attribute,  with  a  prioritization  of  each  attribute’s  relative 
importance.  If  costs  are  additive,  then  the  total  cost  and  total  value  for  the  decision 
maker  are  calculated  as: 

n 

c(xl,x2,...,xn)  =  YJci{xi)  (1) 

Z=1 

where  C;  is  the  cost  associated  with  each  alternative  xL;  and 

n 

v(x1,x2,...,x„)  =  ^v,(x/)  (2) 

(=i 

where  v;  is  the  value  associated  with  each  alternative  x,  (Winston,  1994:774). 

Transformation 

Transformation  is  a  process  by  which  the  military  achieves  and  maintains 
advantage  through  changes  in  operational  concepts,  organization,  and/or 
technologies  that  significantly  improve  its  warfighting  capabilities  or  ability  to 
meet  the  demands  of  a  changing  security  environment.  (USAF  Transformation 
Flight  Plan) 

Since  1990,  the  U.S.  military  has  been  transforming  from  an  industrial-age  to  an 
information-age  force,  and  from  a  Cold  War  to  a  post-Cold  War  force.  Transformation  is 
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ongoing  and  affects  all  aspects  of  the  USAF  including  culture,  capabilities,  and  business 


processes. 

Transformation  requires  a  long-tenn  commitment  and  the  USAF’s  strategy  calls 
for  developing  “transformational”  capabilities  to  support  the  six  “Critical  Operational 
Goals  of  Transformation”  that  emerged  from  the  2001  Quadrennial  Defense  Review 
(QDR).  One  of  the  six  goals  is  discussed  below:  “Leverage  infonnation  technology  and 
innovative  concepts  to  develop  interoperable  Joint  C4ISR.” 

The  QDR  emphasized  end-to-end  Command,  Control,  Communications, 
Computer,  Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  capabilities.  Future 
operational  effectiveness  will  be  dependent  upon  the  Department  of  Defense’s  ability  to 
share  information  both  internally  and  externally,  and  is  the  motivation  for  building  a 
Transformational  Communications  Architecture  (TCA).  The  Global  Infonnation  Grid 
and  how  it  supports  the  needs  of  warfighters  is  a  critical  element  of  the  TCA. 

Global  Information  Grid. 

The  global  information  grid  (GIG)  is  an  adaptive  entity  that  integrates 
communications  systems,  computers  and  information  management  resources  into 
an  intelligent  system-of-systems.  Each  component  of  the  GIG  exchanges 
information  with  other  components,  enabling  the  entire  infrastructure  to  adapt  to 
user  requirements  and  to  stresses  imposed  on  the  network.  This  adaptability  also 
enables  the  infrastructure  to  scale  as  necessary  to  support  force  structure(s)  of 
arbitrary  size,  or  to  incorporate  new  processing,  network  and  communications 
technologies.  (GlobalSecurity.org,  2003) 

The  GIG  is  a  concept,  moving  towards  an  operational  capability,  and  its  ability  to 
exchange  information  has  the  potential  to  be  limited  due  to  connectivity  and 
interoperability  shortfalls.  The  TCA  attempts  to  address  these  issues  and  extend  GIG 
access  to  more  warfighters. 
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Transformational  Communications  Architecture. 

The  Transformational  Communications  Architecture  (TCA)  is  an  end-to-end 
architecture  that  will  enable  the  GIG  and  traverses  the  four  segment  domains  of 
the  DoD-IC-NASA  communications  infrastructure.  The  terminal  segment  is 
composed  of  end-users,  ground  stations,  as  well  as  space  and  airborne  ISR 
tenninals.  The  space  segment  is  composed  of  two  interoperable  satellite 
constellation  rings  (which  can  and  probably  will  operate  in  other  topologies  than 
ring,  e.g.  mesh  connectivity)  and  NASA  as  an  edge  service  with  compatible  space 
and  ground  hardware.  One  of  these  two  rings  is  for  the  Department  of  Defense 
(DoD)  and  another  for  the  Intelligence  Community  (IC)  backbone/relay.  The 
terrestrial  infrastructure  segment  includes  interfaces  to  other  DoD  networks, 
teleports,  NASA  and  National  special  purpose  networks,  and  commercial  systems 
and  selected  ground  systems  RF  communications  ground  stations  for  uplink  and 
downlink,  and  connection  to  the  global  information  grid  -  bandwidth  expansion 
(GIG-BE).  Lastly,  the  network  operations  &  management  segment  is  the  portion 
of  the  TCA  that  connects,  where  deemed  appropriate,  the  ground  networks  of 
DoD,  IC,  and  NASA  managed  by  each  entity  and  supports  peering  across  these 
separately  procured  enclave  systems  so  that  resource  sharing  and  fault  tolerance 
can  be  supported  in  a  system-of-systems  sense.  (GlobalSecurity.org,  2003) 


The  TCA  will  extend  Internet-like  services  directly  to  warfighters,  eliminating  the 
need  to  use  multi-hop  satellite  connections  to  reach  Defense  Information  Switching 
Network  (DISN)  services  through  Standard  Tactical  Entry  Point  (STEP)  sites  located 
thousands  of  miles  from  the  warfighters.  The  decreased  latency  and  increased  bandwidth 
of  the  TCA  will  deliver  an  order  of  magnitude  increase  in  capacity  compared  to  the 
current  architecture. 

A  hierarchical  addressing  scheme  with  the  geostationary  (GEO)  communications 
satellites  acting  as  backbone  routers  has  been  proposed  to  route  real-time  traffic  in  the 
TCA.  Low-earth  orbit  (LEO)  satellites  and  the  high-altitude  platform  (HAP)  aircraft 
serve  as  second  and  third  layer  routers  to  provide  high  bandwidth  with  low  latency  for 
delay-sensitive  transmissions.  The  footprints  of  the  GEO  satellites  are  divided  into 
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stationary  cells  on  the  earth  to  form  one  domain.  Within  that  domain  are  smaller 
footprints  from  various  LEO  satellites,  forming  subdomains.  Finally,  FIAP  aircraft 
footprints  further  divide  subdomains  to  complete  the  hierarchy.  Since  the  GEO  satellite 
footprints  don’t  move,  the  key  references  for  this  topology  are  static.  Using  this 
addressing  scheme,  a  static  connection  matrix  is  easily  maintained  and  is  used  to 
determine  routing.  Figure  3  is  a  diagram  the  TCA  (Durresi,  and  others,  2004:2). 
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Figure  3.  Transformational  Communications  Architecture  (Durresi,  2004:2) 

Communication  can  occur  between  nodes  within  any  one  of  the  three  layers — 
GEO,  LEO,  or  FIAP.  Communication  can  also  be  between  any  two  of  the  three  layers — 
GEO  and  LEO,  GEO  and  FIAP,  or  LEO  and  HAP.  Finally,  it  considers  communication 
between  tactical  users  and  either  of  the  satellite  layers — GEO  or  LEO.  It  does  not 
address  communication  between  the  HAP  layer  and  tactical  users,  and  it  does  not 
consider  the  ability  to  reconfigure  the  network  topology  through  the  use  of  directional 
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communications.  Communication  overhead  for  the  TCA  is  decreased  by  dividing  the 
network  into  domains  using  the  GEO  satellite  footprints  (Durresi,  and  others,  2004:16). 

The  Future 

“Possibly  the  single-most  transfonning  thing  in  our  forces  will  not  be  a  weapon 
system,  but  a  set  of  interconnections  and  a  substantially  enhanced  capability  because  of 
that  awareness.” 

— Secretary  of  Defense  Donald  Rumsfeld,  August  9,  2001. 

(quoted  in  Meyerriecks,  2003) 

In  the  future,  seamless,  interoperable,  global  connectivity  will  be  attained.  An 
Internet  in  the  sky  composed  of  hybrid  communications  capabilities  will  connect  space, 
air,  and  ground  nodes,  eliminating  the  constraint  communications  currently  puts  on 
warfighters.  Figure  4  shows  a  conceptual  drawing  of  future  connectivity. 
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Figure  4.  Future  Connectivity  (Hines,  2004:Slide  43) 


The  Way  Ahead 

There  is  a  large  separation  between  the  realization  of  the  future  vision  and  current 
capability.  Once  the  TCA  infrastructure  begins  construction,  bandwidth  capacity  will, 
most  likely,  come  online  incrementally.  It  is  logical  to  assume  bandwidth  will  be 
constrained  for  the  immediate  future.  It  is  also  logical  to  conclude  priority  access  to 
available  bandwidth  will  also  be  maintained. 

Sender-Receiver  Requirements. 

Traffic  on  a  network  can  be  prioritized  based  on  the  requirements  of  the  senders 
and  receivers  of  the  information.  Military  organizations,  especially,  have  unique  needs 
which  are  closely  tied  to  mission  requirements.  For  example,  Special  Operations  Forces 
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(SOF)  have  unique  characteristics  which  require  their  communications  have  a  low 
probability  of  detection  and  a  low  probability  of  interception  (LPD/LPI).  They  must  also 
be  able  to  operate  covertly  anywhere  in  the  world.  It  is  tempting  to  tailor  current 
technology  to  meet  SOF  needs,  but  given  the  history  with  stovepipe  systems,  creating 
new  families  of  specialized  technology  must  be  done  with  care. 

Summary 

The  need  to  share  information  has  led  to  the  creation  of  tactical  data  networks 
where  warfighters  can  share  information  rapidly.  Unfortunately,  unique  functions  and 
missions  have  also  led  to  the  creation  of  specialized,  stovepipe  systems  which  don’t 
communicate  with  each  other  Advances  in  technology  have  led  to  a  greater  demand  for 
immediate  access  to  infonnation  with  the  Internet  providing  an  example  of  how  easy 
getting  infonnation  can  be.  The  current  communications  infrastructure  cannot  handle  the 
demands  and  expectations  that  advances  in  technology  are  placing  on  it.  Therefore,  a 
TCA  has  been  proposed  to  provide  end-to-end  connectivity,  but  debate  about  terminology 
and  whether  solutions  developed  for  terrestrial  networks  apply.  Military-specific  needs 
might  be  better  captured  in  an  architecture  based  on  the  military  characteristics. 
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III.  Methodology 


Chapter  Overview 

In  this  chapter  the  motivation  and  foundation  for  a  framework  to  be  used  in  the 
discussion  and  analysis  of  topological  decision  making  within  a  TCA.  An  approach  to 
characterizing  user  requirements  and  detennining  measures  of  cost  and  value  associated 
with  a  given  transmission.  I  will  then  describe  a  simulation  scenario  which  represents  an 
instantiation  of  a  TCA,  baseline  its  perfonnance  when  using  a  standard  routing  algorithm 
and  compare  the  results  to  the  same  topology  using  routing  sensitive  to  our  message 
context  vector. 

Characterizing  Requirements 

Organization  affects  thought.  Conversely,  thought  affects  organization.  It  is 
known  that  organizing  communications  based  on  functional  lines  leads  to  stovepiped 
systems  and  problems  with  interoperability.  Starting  from  the  position  that  infonnation  is 
more  important  than  the  system  carrying  it,  a  framework  can  be  built  which  puts 
information  needs  at  its  core.  Once  the  importance  of  information  is  established,  the 
requirement  must  be  specified  in  a  language  which  includes  relevant  tenninology. 

Finally,  once  the  words  and  concepts  to  communicate  with  have  been  defined,  formal 
reasoning  can  justify  why  any  action  should  be  taken  and  its  impact  on  the  overall  ability 
to  pass  information. 

One  of  the  challenges  of  characterizing  anything  is  deciding  how  to  partition  the 
space  of  interest.  Communications  requirements  for  military  users  are  no  exception. 
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There  are  several  obvious  ways  one  can  partition  that  space;  however,  whenever  possible, 
care  must  be  taken  so  the  partitioning  doesn’t  introduce  undesired  long-term  effects. 

One  obvious  way  to  partition  military  communications  is  to  divide  the  space  up 
by  organization.  Since  many  organizations  perform  similar  functions,  this  approach 
would  require  further  division  to  reveal  the  core  characteristics  desired.  Instead,  by  using 
a  functional  organizational  hierarchy  as  the  basis  for  characterizing  communications, 
results  more  along  the  lines  of  what  is  desired  emerge.  Table  1  contains  a 
characterization  based  on  functional  divisions. 


Table  1.  Characterization  of  Communications  Based  on  Function 


Functional  Community 

Characterization  of  Communications 

Fighter 

Real-time  voice  and  data  containing  detailed  threat  and 
target  information 

Bomber 

Real-time  voice  and  data  containing  detailed  target 
information 

Reconnaissance 

Secure,  high-bandwidth  data  with  time-critical  targeting 
information 

Medical 

Time-sensitive  life-saving  data  and  administrative  traffic 

Command  and  Control 

Extensive  real-time  secure  voice  and  data  with  high 
bandwidth  applications 

Personnel 

Mostly  administrative  traffic  containing  some  sensitive 
information 

Maintenance 

Administrative  traffic  with  time-sensitive  logistical  data 

This  approach  begins  with  a  characterization  of  each  functional  area  followed  by 
an  iterative  decomposition  into  parameters.  When  the  list  of  parameters  is  fully 
decomposed,  we  should  have  a  minimal  set  of  parameters,  or  atomic  properties,  required 
to  characterize  our  space;  otherwise,  we  need  to  closely  examine  the  parts  of  our  space 
we  can’t  characterize  for  synergy  which  we  cannot  accurately  represent.  For  example, 
“secure”  is  important  because  it  implies  no  adversary  can  get  the  infonnation,  which 
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further  implies  either  the  information  can’t  be  detected,  intercepted,  or  decrypted;  and 


decryption  implies  both  detection  and  interception.  Hence,  “detectibility”  and 
“interceptibility”  become  two  new  parameters  for  characterizing  communications  in  a 
TCA.  A  proposed  list  of  new  parameters,  definitions,  and  examples  are  found  in  Table  2. 
Well-established  measurable  physical  characteristics  such  as  packet  size,  bandwidth,  and 
propagation  delay  are  not  included  in  the  list,  but  are  still  used  as  needed. 

Table  2.  Characterization  of  Communications  Based  on  Parameters 


Parameter 

Definition 

Example 

Detectibility 

(link) 

A  measure  of  the  likelihood  that 
a  transmission  source  will  be 
detected  by  an  adversary. 

A  laser  link  has  low 
detectibility  because  its 
emissions  are  highly  focused. 

Interceptibility 

(message) 

A  measure  of  the  likelihood  that 
the  contents  of  transmission  will 
be  captured  by  an  adversary. 

An  unencrypted  transmission 
using  an  omnidirectional  RF 
antenna  near  an  enemy 
territory  has  high 
interceptibility  because  an 
adversary  is  likely  to  both 
detect  and  read  the 
information. 

Perishability 

(message) 

A  measure  of  how  long  a 
transmission  will  be  relevant. 

A  computer  system  update 
message  has  high  perishability 
because  current  updates  are 
provided  several  times  every 
second. 

Urgency 

(message) 

A  measure  of  how  fast  a 
transmission  must  reach  its  final 
destination  in  order  to  be  useful. 

An  aircraft  message  stating 
that  its  status  is  “normal”  has 
low  urgency  because  the 
information  will  not  trigger  an 
action  by  the  recipient. 

Criticality 

(message) 

A  measure  of  the  significance  or 
impact  of  a  transmission. 

A  message  stating  that  a  base 
is  under  attack  is  critical 
because  it  indicates  a  change 
in  the  threat  level  for  an  entire 
region. 

The  parameters  above  characterize  communications  in  five  dimensions.  Thus,  a 
class  of  messages  is  represented  using  a  communications  context  vector  composed  of  five 
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variables  describing  message  sensitivity  to  detectibility,  interceptibility,  perishability, 
urgency,  and  criticality.  Similarly,  links  in  a  network  are  described  using  detectibility. 
Vectors  for  communications  traffic  and  the  network  links  may  be  compared  to  determine 
the  propriety  of  a  specific  link  for  the  class  of  message  traffic  being  transmitted. 

NS2  Simulator  and  Representing  Message  Requirements. 

NS2  is  a  widely-accepted,  open-source  discrete  event  network  simulator  available 
from  the  University  of  Southern  California’s  Information  Sciences  Institute  at 
http://www.isi.edu/nsnam/ns/. 

Each  transmitted  message  in  an  instantiated  TCA  has  its  own  requirements  which 
are  described  using  the  communications  parameters  discussed  earlier.  To  perform 
routing  based  on  context,  packet  headers  must  contain  the  parameters  necessary  to 
capture  the  requirements  for  each  individual  packet. 

This  research  is  limited  to  one  class  of  communications  traffic  per  simulation 
scenario.  The  traffic  class  is  described  by  two  parameters — one  capturing  sensitivity  to 
time  delay  and  the  other  capturing  sensitivity  to  signal  detection.  These  parameters  are 
referred  to  as  “delay  sensitivity”  and  “detectibility.”  Delay  sensitivity  is  a  hybrid 
parameter  encapsulating  the  defined  parameters  “perishability”  and  “urgency.”  A  hybrid 
parameter  is  used  because  perishability  and  urgency  are  not  independent — both  relate  to 
time.  Any  amount  of  delay  affects  the  cost  associated  with  each  parameter,  potentially 
resulting  in  two  different  routing  tables  when  either  of  their  values  changes.  Since  the 
simulator  is  limited  to  one  routing  table,  delay  sensitivity  is  used  to  indicate  a  value 
derived  from  a  constant  perishability  and  constant  urgency. 
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To  consider  other  classes  of  traffic,  the  values  of  the  two  parameters  under 
consideration  are  changed  to  produce  four  classes,  as  shown  in  Table  3.  The  four  classes 
are  examined.  Delay  sensitivity  and  detectibility  sensitivity  are  used  in  conjunction  with 
parameters  describing  links  to  determine  total  costs  which  affect  routing.  The  traffic 
classes  are  named  according  to  their  delay  sensitivity-detectibility  sensitivity  pair,  with 
“Low”  representing  the  value  0.3  and  “High”  representing  value  0.8.  For  example,  the 
traffic  class  “High-Low”  has  delay  sensitivity  equal  to  0.3  and  detectibility  sensitivity 
equal  to  0.3. 


Table  3.  Simulation  Scenarios 


Traffic  Class 

Delay  Sensitivity 

Detectibility  Sensitivity 

Low-Low 

0.3 

0.3 

Low-High 

0.3 

0.8 

High-Low 

0.8 

0.3 

High-High 

0.8 

0.8 

Representing  Network  Ability  to  Meet  Message  Requirements. 

Message  sensitivities  describe  what  is  important  to  each  message  in  a  class.  Links  are 
described  using  their  detectibility.  A  link  with  high  detectibility  is  emitting  a  detectible 
signal  which  an  adversary  may  use  to  locate  the  transmitter.  If  a  link  is  detectible,  its 
likelihood  of  detection  may  have  a  direct  relationship  to  the  amount  of  time  the  link  is 
active  (transmitting).  Table  4  gives  some  examples  of  how  detectibility  is  represented. 
The  table  is  not  all-inclusive,  and  the  detectibility  numbers  are  notional.  The  simulations 
we  use  detectibility  values  of  0  and  1 . 
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Table  4.  Link  Detectibility 


Link  Type 

Detectibility 

Rationale 

Free-space  optical  laser 

0.00 

A  narrow  beam  must  hit  detector 
directly  to  be  detected. 

Low-power, 
directional  RF 

0.20 

Detector  must  lie  in  the  same 
direction  from  the  transmitter  as  the 
receiver  and  must  be  within  range,  or 
take  advantage  of  inevitable  side-lobe 
emissions. 

Fligh-power, 
directional  RF 

0.45 

Detector  must  lie  in  the  same 
direction  from  the  transmitter  as  the 
receiver  and  can  be  at  a  greater  range 
than  the  receiver,  or  take  advantage 
of  inevitable  side-lobe  emissions. 

Low-power, 
omnidirectional  RF 

0.60 

Detector  can  lie  in  any  direction  but 
and  must  be  within  range. 

Fligh-power, 
omnidirectional  RF 

0.85 

Detector  can  lie  in  any  direction  but 
and  can  be  at  a  greater  range  than  the 
receiver. 

Fligh-power, 
multi-frequency, 
omnidirectional  RF 

0.95 

Detection  is  possible  from  any 
direction  at  long  range  and  on  various 
frequencies. 

Cost  Function 

Routing  in  the  TCA  is  accomplished  using  a  cost  function  based  on  parameters 
from  messages  and  links.  The  cost  associated  with  transmitting  one  packet  from  a 
specific  message  class  across  a  specific  link  has  two  parts,  Delay  Cost  and  Detectibility 
Cost,  and  is  defined  as: 

Per  Packet  Cost  =  Delay  Cost  +  Detectibility  Cost 

where 

Delay  Cost  =  Delay  Sensitivity*(Packet  Size/Bandwidth  +  Propagation  Delay  +  Queuing  Delay) 

and 

Detectibility  Cost  =  Detectibility  Sensitivity  *  (Packet  Size/Bandwidth) 
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Using  the  above  cost  equations,  the  total  cost  is  calculated  by  summing  the 
individual  packet  costs  for  each  link  a  packet  traverses.  Bandwidth  is  used  to  compare 
the  performance  of  the  scenarios. 


Simulation  Model 

The  simulation  models  a  TCA  composed  of  17  nodes  described  in  Table  5.  Each 
satellite  has  only  laser-optical  links,  while  the  remaining  nodes  have  either  a  single  link 
or  a  combination  or  laser-optical  and  RF  links.  The  “Detectible”  column  in  Appendix  A, 
Table  10  indicates  whether  or  not  the  links  in  the  TCA  are  detectible. 


Table  5.  Simulated  Transformational  Communication  Architecture 


Layer 

Description 

Nodes 

Example 

GEO 

Geostationary  Satellites 

0,1,2 

Wide-area 

Communications 

Satellites 

LEO 

Low-Earth  Orbit  Satellites 

3,4,5 

Regional 

Communications 

Satellites 

HAP 

High-Altitude  Platforms 

6,7 

High-Altitude 
Aircraft  with  long 
loitering  times 

LAP 

Low-Altitude  Platforms 

8,9,10,11 

Remotely-Piloted  or 
Unmanned  Aerial 
Vehicles  (UAV) 

GLP 

Ground-Layer  Platforms 

12,13,14,15,16 

Military  Bases 

All  layers  can  communicate  with  adjacent  layers.  All  nodes,  except  for  GLP 
nodes,  can  communicate  within  their  own  layer.  TCA  topology  is  shown  in  Figure  5. 
Node  0  represents  “reach  back”  connectivity  to  distant  locations,  such  as  from  a  theater 
of  operations  back  to  the  continental  U.S.  Node  0  has  a  longer  delay  due  to  the  greater 
distance  involved. 


30 


Simulation  Message  Transmissions 

A  message  set  was  chosen  to  represent  the  types  of  traffic  one  might  see  during 
real-world  military  operation.  It  includes  communications  between  various  nodes 
traveling  across  links  in  both  directions.  The  transmissions  arrive  according  to  a  Poisson 
process  with  packet  size  of  1000  bytes.  There  are  17  transmissions  between  9  source- 
destination  pairs,  as  shown  in  Table  6.  The  amount  of  data  transmitted  from  each  node  is 
designed  to  approximate  classes  of  military  data  including  intelligence  imagery, 
intelligence  messages,  UAV  video,  UAV  command  and  control,  diplomatic 
communications,  general  command  and  control,  status  reports,  medical  diagnostic,  and 
general  mission-related  traffic.  The  same  transmission  set  characteristics  are  used  for  all 
simulation  runs. 
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Table  6.  Message  Transmissions 


Source 

Destination 

Offered  Load 

Node 

Node 

(Kbits/sec) 

0 

12 

16.0 

14 

10.0 

15 

11.4 

7 

6 

20.0 

13 

11.4 

15 

11.4 

8 

13 

26.7 

9 

13 

26.7 

12 

0 

80.0 

0 

80.0 

13 

0 

80.0 

8 

40.0 

9 

40.0 

14 

15 

80.0 

15 

0 

26.7 

16 

6 

22.9 

7 

22.9 

Baseline  Simulation 

The  baseline  simulation  scenario  uses  NS2’s  implementation  of  Dijkstra’s  All- 
Pairs  Shortest  Path  Routing  Algorithm  to  compute  the  traffic  routes  for  the  TCA. 
Simulation  statistics  on  the  number  of  packets  flowing  over  each  link  are  collected  for  the 
message  set  described  earlier.  The  cost  function  calculates  the  total  cost  that  would  have 
resulted  using  the  routing  table  computed  by  Dijkstra’s  algorithm  for  each  of  the  four  test 
cases.  This  data  is  compared  to  the  results  obtained  from  using  the  context-based  routing. 

Scenarios 

Four  scenarios  are  specified  in  Table  3  for  Low-Low,  Low-High,  High-Low,  and 
High-High  parameters.  Using  these  parameters  and  the  cost  function,  costs  are  computed 
and  context-based  routing  table  is  built  for  each  test  case.  Simulations  are  run  with  each 
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of  the  four  new  routing  tables  and  the  number  of  packets  flowing  over  each  link  are 
recorded.  Total  cost  associated  with  each  new  routing  table  is  computed  and  compared 
with  the  cost  the  new  packet  flows  would  have  incurred  using  the  costs  associated  with 
the  routing  from  the  baseline.. 

Summary 

This  chapter  described  the  tenninology  and  cost  and  value  functions  used  our 
TCA  framework.  It  detailed  the  topology  and  test  cases  used  to  simulate  the  TCA,  as 
well  as  a  general  procedure  for  the  comparisons  that  are  accomplished  in  the  upcoming 
analysis. 
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IV.  Analysis  and  Results 


Chapter  Overview 

The  new  framework  for  routing  and  decision-making  within  a  TCA  showed  an 
improvement  over  Dijkstra’s  algorithm  in  selecting  routes  based  on  message 
requirements.  Compared  to  the  baseline,  cost  improved  for  all  of  the  test  cases,  while 
performance  improved  slightly  in  one  case. 

Results  of  Simulation  Scenarios 

NS2  computed  the  best  routes  using  Dijkstra’s  algorithm.  By  counting  the 
number  of  packets  that  flowed  over  each  link  in  the  topology,  the  costs  that  would  have 
incurred  had  these  same  packets  been  assigned  context  parameters.  The  packet  flows  and 
cost  comparison  using  the  baseline  data  are  captured  in  Table  7.  Additional  calculations 
may  be  found  in  Appendix  A.  In  calculating  the  cost,  the  number  of  packets  traversing 
each  link  remained  constant.  The  two  parameters  weighted  each  component  of  cost 
differently,  resulting  in  the  different  totals  found  at  the  bottom  of  the  table. 
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Table  7.  Baseline  Packet  Flows  and  Costs 


From 

Node 

To 

Node 

Dijkstra 

Packets 

Low- Low 
Per  Packet 
Cost 

Low- Low 

Dijkstra 

Cost 

Low- Low 

Per  Packet 
Cost 

Low-High 

Dijkstra 

Cost 

High-Low 
Per  Packet 
Cost 

High-Low 

Dijkstra 

Cost 

High-High 
Per  Packet 
Cost 

High-High 

Dijkstra 

Cost 

0 

i 

2574 

0.0371 

95.52 

0.0371 

95.52 

0.0990 

254.72 

0.0990 

254.72 

1 

0 

{■mi] 

0.0371 

0.0371 

198.87 

0.0990 

530.33 

0.0990 

530.33 

1 

2 

0 

0.0016 

0.00 

0.0016 

0.00 

0.0043 

0.00 

0.0043 

0.00 

1 

3 

1831 

0.0355 

64.98 

0.0355 

64.98 

0.0946 

173.29 

0.0946 

173.29 

1 

4 

ffrlM 

0.0355 

iksb 

0.0355 

26.37 

0.0946 

70.32 

0.0946 

70.32 

2 

1 

0 

0.0016 

0.00 

0.0016 

0.00 

0.0043 

0.00 

0.0043 

0.00 

2 

4 

0 

0.0355 

0.00 

0.0355 

0.00 

0.0946 

0.00 

0.0946 

0.00 

2 

5 

0 

0.0355 

0.00 

0.0355 

0.00 

0.0946 

0.00 

0.0946 

0.00 

3 

i 

PggEETi] 

0.0355 

159.35 

0.0355 

159.35 

0.0946 

424.94 

0.0946 

424.94 

3 

4 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

3 

6 

0.0005 

0.88 

0.0005 

0.88 

0.0013 

2.36 

0.0013 

2.36 

4 

1 

0.0355 

30.84 

0.0355 

30.84 

0.0946 

82.24 

0.0946 

82.24 

4 

2 

0 

0.0355 

0.00 

0.0355 

0.00 

0.0946 

0.00 

0.0946 

0.00 

4 

3 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

4 

5 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

4 

6 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

4 

7 

UIII! 

0.0005 

0.0005 

0.36 

0.0013 

0.96 

0.0013 

0.96 

5 

2 

0 

0.0355 

0.00 

0.0355 

0.00 

0.0946 

0.00 

0.0946 

0.00 

5 

4 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

5 

7 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

6 

3 

'SSEE3 

0.0005 

2.17 

0.0005 

2.17 

0.0013 

5.78 

0.0013 

5.78 

6 

4 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

6 

7 

0 

0.0003 

0.00 

0.0004 

0.00 

0.0009 

0.00 

0.0009 

0.00 

6 

8 

0.0010 

2.05 

0.0018 

3.76 

0.0018 

3.76 

0.0026 

5.47 

6 

9 

785 

0.0005 

0.38 

0.0005 

0.38 

0.0013 

1.00 

0.0013 

1.00 

7 

4 

0.0005 

0.42 

0.0005 

0.42 

0.0013 

1.12 

0.0013 

1.12 

7 

5 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

7 

6 

JEHU 

0.0003 

1.04 

0.0004 

1.09 

0.0009 

2.74 

0.0009 

2.78 

7 

0.0010 

1.41 

0.0018 

2.59 

0.0018 

2.59 

0.0026 

3.76 

7 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

8 

6 

MBEfelil 

0.0010 

4.31 

0.0018 

7.90 

0.0018 

7.90 

0.0026 

11.49 

8 

9 

0 

0.0011 

0.00 

0.0019 

0.00 

0.0022 

0.00 

0.0030 

0.00 

8 

ms 

V«iEM 

0.0012 

1.26 

0.0012 

1.26 

0.0032 

3.35 

0.0032 

3.35 

8 

ms 

2272 

0.0024 

5.45 

0.0044 

10.00 

0.0044 

10.00 

0.0064 

14.54 

9 

6 

0 

0.0005 

0.00 

0.0005 

0.00 

0.0013 

0.00 

0.0013 

0.00 

9 

8 

0 

0.0011 

0.00 

0.0019 

0.00 

0.0022 

0.00 

0.0030 

0.00 

9 

10 

0 

0.0011 

0.00 

0.0019 

0.00 

0.0022 

0.00 

0.0030 

0.00 

9 

ms 

951 

0.0012 

1.14 

0.0012 

1.14 

0.0032 

3.04 

0.0032 

3.04 

9 

ms 

785 

0.0024 

1.88 

0.0044 

3.45 

0.0044 

3.45 

0.0064 

5.02 

Bgg] 

7 

I9E^] 

0.0010 

0.83 

0.0018 

1.53 

0.0018 

1.53 

0.0026 

2.22 

9 

0 

0.0011 

0.00 

0.0019 

0.00 

0.0022 

0.00 

0.0030 

0.00 

11 

0 

0.0011 

0.00 

0.0019 

0.00 

0.0022 

0.00 

0.0030 

0.00 

ms 

0 

0.0012 

0.00 

0.0012 

0.00 

0.0032 

0.00 

0.0032 

0.00 

ms 

0.0024 

7.26 

0.0044 

13.30 

0.0044 

13.30 

0.0064 

19.35 

7 

0.0005 

1.07 

0.0005 

1.07 

0.0013 

2.86 

0.0013 

2.86 

BKK! 

0 

0.0011 

0.00 

0.0019 

0.00 

0.0022 

0.00 

0.0030 

0.00 

ms 

0 

0.0012 

0.00 

0.0012 

0.00 

0.0032 

0.00 

0.0032 

0.00 

tmn 

16 

0 

0.0024 

0.00 

0.0044 

0.00 

0.0044 

0.00 

0.0064 

0.00 

ms 

8 

0.0012 

0.0012 

3.64 

0.0032 

9.70 

0.0032 

9.70 

ms 

8 

0.0024 

6.86 

0.0044 

12.57 

0.0044 

12.57 

0.0064 

18.28 

mm 

9 

1291 

0.0012 

1.55 

0.0012 

1.55 

0.0032 

4.13 

0.0032 

4.13 

ms 

9 

0 

0.0024 

0.00 

0.0044 

0.00 

0.0044 

0.00 

0.0064 

0.00 

mm 

10 

1554 

0.0012 

1.86 

0.0012 

1.86 

0.0032 

4.97 

0.0032 

4.97 

ms 

0.0024 

2.09 

0.0044 

3.82 

0.0044 

3.82 

0.0064 

5.56 

ms 

0 

0.0012 

0.00 

0.0012 

0.00 

0.0032 

0.00 

0.0032 

0.00 

ms 

*»*VT-ZT 

0.0024 

5.37 

0.0044 

9.85 

0.0044 

9.85 

0.0064 

14.32 

TOTALS 

629.22 

660.53 

1646.62 

1677.92 
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The  cost  values  for  the  Low-Low  scenario  which  are  contained  in  the  “Low-Low 


Dijkstra  Cost”  column  in  Table  7  were  assigned  to  the  topology  to  construct  the  diagram 
in  Figure  6.  The  baseline  routing  table  in  Figure  7  was  computed  using  Dijkstra’s 
algorithm  and  mapped  the  path  from  Node  0  to  Node  12.  The  shaded  cells  indicate  links 
that  packets  flowed  across  in  the  baseline  scenario.  These  nodes  were  used  to  start 
because  it  was  known  that  there  was  a  message  from  Node  0  to  Node  12.  The  Dijkstra 
route  was  superimposed  on  top  of  the  link  cost  diagram  and  visually  inspected  the 
alternatives  to  find  a  minimal  span. 

In  general,  it  is  easy  to  find  a  minimum  spanning  tree  for  any  given  network,  but 
the  problem  becomes  much  more  challenging  as  the  number  of  routing  criteria  grows 
beyond  one-dimensional  values  like  hop-count  or  delay.  A  minimum  spanning  tree  can 
still  be  found  if  the  traffic  is  specified  along  with  all  criteria  for  all  flows  in  the  network, 
at  the  price  of  additional  computation,  but  it  is  far  more  difficult  to  find  a  general  answer 
for  any  traffic  pattern  than  it  is  in  traditional  networks.  Instead,  a  simple  visual 
inspection  of  the  links  for  the  route  with  cheaper  cost  was  done.  One  was  found  and  the 
process  was  repeated  for  all  message  traffic  to  create  the  new  routing  table  in  Figure  8. 
The  shaded  cells  in  the  context-based  routing  tables  indicate  routes  different  from 
Dijkstra’s  baseline  routing  table.  The  context-based  routing  tables  for  the  other  three 
scenarios  were  computed  in  the  same  manner.  The  remaining  routing  tables  may  be 
found  in  Appendix  A. 
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Link  Costs  (Low-Low) 


Figure  6.  Low-Low  Scenario  Link  Costs 
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Figure  7.  Baseline  Routing  Table 
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Figure  8.  Low-Low  Scenario  Context-Based  Routing  Table 

The  context-based  routing  tables  were  used  to  reprogram  the  routes  used  by  the 
simulator  and  the  simulations  were  rerun  for  each  scenario.  The  new  packet  flows  and 
the  costs  associated  with  each  scenario  are  recorded  Table  8.  New  packet  routes  resulted 
in  a  different  number  of  packets  flowing  over  each  link  and  the  new  costs  listed  in  the 
table. 
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Table  8.  Scenario  Packet  Flows  and  Costs 
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The  motivation  for  creating  our  scenario  was  to  perform  system-level 
performance  analysis.  By  focusing  on  the  total  number  of  packets  and  not  their  timings, 
variations  have  been  effectively  eliminated  from  the  simulation  analysis.  The  Poisson 
process  used  to  generate  the  packets  creates  an  expected  number  of  packets  and 
distributes  them  over  a  time  interval.  Since  we  combine  all  intervals  to  get  our  packet 
count,  we  get  the  original  number  simulator  started  with — it  is  detenninistic  and  doesn’t 
change  no  matter  how  often  we  run  the  simulation.  Future  work  will  not  be  limited  to  a 
single  class  of  traffic,  so  variations  in  packet  sizes,  routing  tables,  and  context  parameters 
will  enable  a  more  extensive  analysis. 

Investigative  Questions  Answered 

According  to  the  cost  metric  derived  earlier,  the  new  routing  outperforms 
Dijkstra’s.  This  is  to  be  expected  as  these  costs  are  not  considered  in  Dijkstra’s 
algorithm.  When  context-based  routes  were  used,  packet  flows  through  the  system 
increased  and  cost  decreased,  as  indicated  in  Table  9.  The  context-based  routes  were 
better  suited  to  meet  the  needs  of  the  message  traffic  flowing  through  the  network. 
Increases  in  the  number  of  packets  traversing  links  are  a  direct  result  of  the  attempt  to 
achieve  lower  cost  by  routing  packets  differently.  However,  since  our  cost  equation  uses 
link  bandwidth  in  the  denominator  of  both  the  detectibility  and  delay  contributions  to 
cost,  it  is  reasonable  to  expect  that  an  increase  in  system  bandwidth  would  accompany  a 
lower  overall  cost.  More  detailed  simulation  and  analysis  is  needed  to  make  that 
determination. 
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Table  9.  Comparison  of  Context-Based  and  Dijkstra  Packets  and  Costs 


Dijkstra 

Packets 

Low-Low 

Packets 

Low- Low 
Cost 

Low-High 

Packets 

Low-High 

Cost 

High-Low 

Packets 

High-Low 

Cost 

High-High 

Packets 

High-High 

Cost 

Dijkstra 

58705 

Context-Based 

62664 

|  608.241 

61879 

58705 

1637.841 

62664 

%  Improvement 
over  Dijkstra 

6.74% 

3.34% 

5.41% 

6.25% 

0.00% 

0.53% 

6.74% 

3.34% 

Since  the  cost  function  is  based  on  a  linear  function  of  the  parameters  for 
sensitivities  to  delay  and  detection,  the  corresponding  packet  count  and  cost  values  for 
any  two  scenarios  where  the  sensitivities  to  delay  and  detection  are  equal  should  be  the 
same.  Results  for  the  Low-Low  and  High-High  scenarios  confirm  this. 

Local  cost  is  partially  dependent  on  link  bandwidth,  but  the  relationship  between 
total  cost  and  system  bandwidth  has  not  been  determined.  Figure  9  shows  the  bandwidth 
comparison  between  the  Dijkstra  baseline  and  the  Low-Low  scenario.  The  Dijkstra 
baseline  experienced  a  higher  effective  bandwidth  throughout  most  of  the  simulation, 
resulting  in  the  Low-Low  scenario  having  a  4.68%  system  bandwidth  improvement  over 
the  Dijkstra  baseline.  The  bandwidth  calculations  and  remaining  bandwidth  loss  scenario 
figures  are  included  in  Appendix  A.  The  system  bandwidth  is  summarized  in  Table  10, 
which  shows  an  improvement  for  only  one  of  the  four  scenarios. 
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Bandwidth  Comparison  (Dijkstra  vs  Low-Low) 


- Dijkstra 

Bandwidth 
(Mbits/sec) 
■  Low-Low 
Bandwidth 
(Mbits/sec) 


Figure  9.  Bandwidth  (Dijkstra  vs  Low-Low) 

The  High-Low  scenario  was  the  only  one  which  showed  a  system  bandwidth 
improvement  over  the  Dijkstra  baseline.  Once  again,  the  Low-Low  and  High-High 
scenarios  were  duplicate  images  of  each  other.  The  Low-Low,  Low-High,  and  High- 
High  scenarios  each  showed  a  4.68%  decrease  in  effective  system  bandwidth  compared 
to  the  Dijkstra  baseline.  This  decrease  was  calculated  by  averaging  each  scenario’s 
bandwidth  over  the  60  time  intervals  and  comparing  them  to  the  average  from  the 
Dijkstra  baseline.  Our  new  routings  adversely  affected  overall  system  performance  in 
most  cases.  The  interesting  case  is  the  High-Low  scenario  which  showed  a  0.56%  system 
bandwidth  increase.  There  was  also  an  accompanying  cost  improvement  for  this 
scenario.  Since  cost  improved  in  all  cases  and  bandwidth  improved  in  only  one  case,  the 
results  suggest  that  we  don’t  have  enough  information  to  correlate  the  two.  The  non- 


42 


random  nature  of  our  traffic  load  clouds  the  meaning  of  the  changes  in  system  bandwidth. 
The  routing  table  for  the  High-Low  scenario  in  Appendix  A,  Figure  14,  indicates  that 
additional  links  are  traversed  in  some  cases  because  the  high  sensitivity  to  detection 
wants  to  achieve  a  lower  cost,  not  necessarily  a  lower  hop  count.  The  additional  hops 
may  relieve  congestion  at  adjacent  nodes,  resulting  in  the  increased  bandwidth. 

Summary 

The  Dijkstra  baseline  scenario  was  used  to  project  routes  more  suitable  to  our 
message  sensitivities.  As  expected,  the  new  context-based  routes  showed  across-the- 
board  improvements  in  cost.  Packet  flows  were  at  least  as  high  as  the  Dijkstra  baseline 
for  every  scenario,  and  system  bandwidth  improved  in  one  case.  While  improved  costs 
were  directly  related  to  our  routing  changes,  the  bandwidth  improvement  may  have  been 
caused  by  other  factors. 
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Table  10.  System  Bandwidth  Summary 


V.  Conclusions  and  Recommendations 


Chapter  Overview 

In  this  chapter  the  research  conclusions  and  their  significance  is  presented. 
Recommendations  for  future  work  are  discussed. 

Conclusions  of  Research 

Terminology  for  five  new  communications  parameters  was  successfully  created  to 
better  identify  military  communications  requirements.  The  new  tenninology  is  able  to 
describe  military  requirements  in  terms  more  relevant  than  was  possible  before  with 
standard  computer  communications  network  terminology.  A  routing  cost  function  was 
devised  with  the  new  tenninology  and  successfully  routed  packets  through  the  TCA  in  a 
manner  more  consistent  with  user  needs  than  was  observed  when  using  Dijkstra’s  All- 
Pairs  Shortest  Path  routing  algorithm. 

Significance  of  Research 

This  research  provides  a  more  suitable  approach  for  representing  user 
requirements  and  more  effectively  addresses  warfighter  needs.  New  tenninology  created 
by  this  research  allows  routing  paths  tailored  to  user-approved  context  of  each  individual 
packet.  This  capability  could  result  in  the  better  utilization  of  limited  resources  such  as 
hard-to-detect  laser  links.  Also,  since  the  TCA  and  tenninology  can  account  for  link 
types,  it  now  becomes  feasible  to  reconfigure  the  TCA  topology  based  on  user 
requirements  in  conjunction  with  network  performance,  not  just  performance  alone. 
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Recommendations  for  Future  Research 


This  thesis  provides  an  initial  look  at  defining  terminology  which  will  allow  us  to 
more  appropriately  define  user  requirements  and  potentially  take  greater  advantage  of  the 
capabilities  of  a  TCA.  A  more  in-depth  analysis  is  needed  in  order  to  better  understand 
the  implications.  Our  recommendations  for  future  research  include: 

•  Re-examine  the  communications  terminology  and  modify  the  parameter 
definitions  to  make  them  all  mathematically  independent  of  each  other.  This 
should  help  improve  understanding  of  how  each  parameter  affects 
performance. 

•  Build  a  new  cost  function  based  on  all  of  the  communications  parameters  and 
use  it  in  conjunction  with  an  updated  simulator  which  has  been  modified  to 
route  packets  based  on  the  parameter  values.  Include  random  packet  sources 
and  destinations  to  eliminate  dependencies  on  deterministic  traffic  flows  from 
the  results.  This  will  provide  a  more  realistic  simulation  for  the  TCA. 

•  Incorporate  the  Downhill  Simplex  Method  in  Multidimensions  algorithm  into 
the  packet  routing  logic  of  the  simulator  to  find  the  minimum  cost  of  a 
function  of  more  than  one  independent  variable  (Press,  and  others,  1992:408). 
Investigate  how  the  algorithm  might  be  used  offline  to  identify  the  best  routes 
for  all  packet  types  traveling  from  any  node  to  any  other  node. 

•  Investigate  how  a  “Communications  Tasking  Order”  might  be  created 
automatically  to  direct  slewable  TCA  links  to  change  the  network  topology  in 
order  to  achieve  a  desired  effect. 

Summary 

This  research  presents  a  framework  for  routing  and  topological  decision-making 
within  a  Transformational  Communications  Architecture.  Five  terms  were  presented  to 
more  precisely  capture  user  requirements.  Two  of  the  tenns  were  used  to  create  a  packet 
routing  cost  function  and  a  simulation  was  conducted  to  show  the  feasibility  of  the 
approach.  The  cost  function  resulted  in  packet  routing  which  more  closely  matched  user 
requirements  and  improved  system  perfonnance  under  most  scenarios.  The  relationship 
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between  system  performance  and  the  cost  function  could  not  be  clearly  determined. 
Finally,  recommendations  for  future,  related  research  efforts  were  proposed. 
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Appendix  A.  Related  Data  and  Calculations 


Table  11.  Calculation  of  Low-Low  Scenario  Total  Cost  Per  Packet 


0.3  Delay  Sensitivity  This  table  is  used  to  calculate  costs  using  the  routes  from  Dijkstra's  All-Pairs  algorithm. 

0.3  Detectibility  These  costs  are  used  to  calculate  better  (lower  cost)  routes  based  on  context. 
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Table  12.  Calculation  of  Low-High  Scenario  Total  Cost  Per  Packet 


0.3  Delay  Sensitivity  This  table  is  used  to  calculate  costs  using  the  routes  from  Dijkstra's  All-Pairs  algorithm. 

0.8  Detectibility  These  costs  are  used  to  calculate  better  (lower  cost)  routes  based  on  context. 
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0.03711 

0.00000 

0.03711 

1 

2 

BlilililililililtltltJ 

0 

0.00540 

0.00162 

0.00000 

0.00162 

1 

3 

0 

0.11830 

0.03549 

0.00000 

0.03549 

1 

4 

0 

0.11830 

0.03549 

0.00000 

0.03549 

2 

1 

0 

0.00540 

0.00162 

0.00000 

0.00162 

2 

4 

0 

0.11830 

0.03549 

0.00000 

0.03549 

2 

5 

0 

0.11830 

0.03549 

0.00000 

0.03549 

3 

1 

0 

0.11830 

0.03549 

0.00000 

0.03549 

3 

4 

0 

0.00160 

0.00048 

0.00000 

0.00048 

3 

6 

■IiIiMiMiIiMi] 

0 

0.00160 

0.00048 

0.00000 

0.00048 

4 

1 

0 

0.11830 

0.03549 

0.00000 

0.03549 

4 

2 

0 

0.11830 

0.03549 

0.00000 

0.03549 

4 

3 

0 

0.00160 

0.00048 

0.00000 

0.00048 

4 

5 

0 

0.00160 

0.00048 

0.00000 

0.00048 

4 

6 

■liltlililililiWil 

0 

0.00160 

0.00048 

0.00000 

0.00048 

4 

7 

■1.I.M.M.I.M.1 

0 

0.00160 

0.00048 

0.00000 

0.00048 

5 

2 

0 

0.11830 

0.03549 

0.00000 

0.03549 

5 

4 

iMiIiIiIiWiWtl*] 

0 

0.00160 

0.00048 

0.00000 

0.00048 

5 

7 

mmmim 

0 

0.00160 

0.00048 

0.00000 

0.00048 

6 

3 

■I.I.W.W.M.M 

0 

0.00160 

0.00048 

0.00000 

0.00048 

6 

4 

mmwmm 

0 

0.00160 

0.00048 

0.00000 

0.00048 

6 

7 

mtumm 

1 

0.00110 

■iMiliMl 

mmwfm 

■JiMiMH 

6 

8 

1 

0.00000 

0.00048 

0.00128 

0.00176 

6 

9 

0 

0.00000 

0.00048 

0.00000 

0.00048 

7 

4 

0 

0.00160 

0.00048 

0.00000 

0.00048 

7 

5 

■I.I.1.W.W.W.1 

0 

0.00160 

0.00048 

0.00000 

0.00048 

7 

6 

■sMIilililililil 

1 

0.00110 

■riliMiW 

■iWiWtld 

7 

10 

1 

0.00000 

0.00048 

0.00128 

0.00176 

7 

11 

0 

0.00000 

0.00048 

0.00000 

0.00048 

8 

6 

1 

0.00000 

0.00048 

0.00128 

0.00176 

8 

9 

1 

0.00050 

0.00063 

0.00128 

0.00191 

8 

12 

0 

0.00000 

0.00120 

0.00000 

0.00120 

8 

13 

1 

0.00000 

0.00120 

0.00320 

0.00440 

9 

6 

0 

0.00000 

0.00048 

0.00000 

0.00048 

9 

8 

1 

0.00050 

0.00063 

0.00128 

0.00191 

9 

10 

1 

0.00050 

0.00063 

0.00128 

0.00191 

9 

0 

0.00000 

0.00120 

0.00000 

0.00120 

9 

14 

1 

0.00000 

0.00120 

0.00320 

0.00440 

7 

1 

0.00000 

0.00048 

0.00128 

0.00176 

HE 

9 

1 

0.00050 

0.00063 

0.00128 

0.00191 

■Q 

11 

1 

0.00050 

0.00063 

0.00128 

0.00191 

HI 

14 

0 

0.00000 

0.00120 

0.00000 

0.00120 

H 

15 

1 

0.00000 

0.00120 

0.00320 

0.00440 

11 

7 

0 

0.00000 

0.00048 

0.00000 

0.00048 

11 

10 

1 

0.00050 

0.00063 

0.00128 

0.00191 

11 

15 

0 

0.00000 

0.00120 

0.00000 

0.00120 

11 

1 

0.00000 

0.00120 

0.00320 

0.00440 

mm 

8 

0 

0.00000 

0.00120 

0.00000 

0.00120 

m 

8 

1 

0.00000 

0.00120 

0.00320 

0.00440 

ME 

9 

0 

0.00000 

0.00120 

0.00000 

0.00120 

mm 

9 

1 

0.00000 

0.00120 

0.00320 

0.00440 

ME 

10 

0 

0.00000 

0.00120 

0.00000 

0.00120 

lass 

10 

1 

0.00000 

0.00120 

0.00320 

0.00440 

HSS3 

11 

0 

0.00000 

0.00120 

0.00000 

0.00120 

|16^ 

11 

2000000| 

1 

0.00000 

I'K'iK'l 
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Table  13.  Calculation  of  High-Low  Scenario  Total  Cost  Per  Packet 


0.8  Delay  Sensitivity  This  table  is  used  to  calculate  costs  using  the  routes  from  Dijkstra's  All-Pairs  algorithm. 

0.3  Detectibility  These  costs  are  used  to  calculate  better  (lower  cost)  routes  based  on  context. 

1000  Packet  Size  (bytes)  _ _ _ _ _ 


From 

Node 

To 

Node 

Bandwidth 

(bps) 

Detectible 
0  =  No 

1  =  Yes 

Propagation 

+ 

Queue  Delay 
(sec) 

Delay 

Sensitivity 

Cost 

Detectibility 

Cost 

Total  Cost 
Per 
Packet 

0 

1 

0 

0.12370 

1 

0 

0 

0.12370 

0.09896 

0.00000 

0.09896 

1 

2 

BMiIOIiIiIiItliliJ 

0 

0.00540 

0.00432 

0.00000 

0.00432 

1 

3 

0 

0.11830 

0.09464 

0.00000 

0.09464 

1 

4 

0 

0.11830 

0.09464 

0.00000 

0.09464 

2 

1 

0 

0.00540 

0.00432 

0.00000 

0.00432 

2 

4 

0 

0.11830 

0.09464 

0.00000 

0.09464 

2 

5 

0 

0.11830 

0.09464 

0.00000 

0.09464 

3 

1 

0 

0.11830 

0.09464 

0.00000 

0.09464 

3 

4 

0 

0.00160 

0.00128 

0.00000 

0.00128 

3 

6 

■MMiMiIiIiIi] 

0 

0.00160 

0.00129 

0.00000 

0.00129 

4 

1 

0 

0.11830 

0.09464 

0.00000 

0.09464 

4 

2 

0 

0.11830 

0.09464 

0.00000 

0.09464 

4 

3 

imummmi 

0 

0.00160 

0.00128 

0.00000 

0.00128 

4 

5 

nnmmmoi 

0 

0.00160 

0.00128 

0.00000 

0.00128 

4 

6 

■t.l.I.I.I.I.W.1.1 

0 

0.00160 

0.00129 

0.00000 

0.00129 

4 

7 

■MiIiIiIiIiIiMiI 

0 

0.00160 

0.00129 

0.00000 

0.00129 

5 

2 

0 

0.11830 

0.09464 

0.00000 

0.09464 

5 

4 

BIiIiIiMiIiIOIiIiJ 

0 

0.00160 

0.00128 

0.00000 

0.00128 

5 

7 

■IiIiMiMiMiIi] 

0 

0.00160 

0.00129 

0.00000 

0.00129 

6 

3 

0 

0.00160 

0.00129 

0.00000 

0.00129 

6 

4 

■I.I.W.W.M.M 

0 

0.00160 

0.00129 

0.00000 

0.00129 

6 

7 

mumma 

1 

0.00110 

EgaSl 

■mmiiiii 

6 

8 

1 

0.00000 

0.00128 

0.00048 

0.00176 

6 

9 

0 

0.00000 

0.00128 

0.00000 

0.00128 

7 

4 

mmwfflffli 

0 

0.00160 

0.00129 

0.00000 

0.00129 

7 

5 

■IiIiMiIiMiIiM 

0 

0.00160 

0.00129 

0.00000 

0.00129 

7 

6 

■MI.M.M.M 

1 

0.00110 

EHH 

■mniiiiii 

7 

10 

1 

0.00000 

0.00128 

0.00048 

0.00176 

7 

11 

0 

0.00000 

0.00128 

0.00000 

0.00128 

8 

6 

1 

0.00000 

0.00128 

0.00048 

0.00176 

8 

9 

1 

0.00050 

0.00168 

0.00048 

0.00216 

8 

12 

0 

0.00000 

0.00320 

0.00000 

0.00320 

8 

13 

1 

0.00000 

0.00320 

0.00120 

0.00440 

9 

6 

0 

0.00000 

0.00128 

0.00000 

0.00128 

9 

8 

1 

0.00050 

0.00168 

0.00048 

0.00216 

9 

10 

1 

0.00050 

0.00168 

0.00048 

0.00216 

9 

§KE3 

0 

0.00000 

0.00320 

0.00000 

0.00320 

9 

14 

1 

0.00000 

0.00320 

0.00120 

0.00440 

H 

7 

1 

0.00000 

0.00128 

0.00048 

0.00176 

H 

9 

1 

0.00050 

0.00168 

0.00048 

0.00216 

HI 

11 

1 

0.00050 

0.00168 

0.00048 

0.00216 

BUS 

14 

0 

0.00000 

0.00320 

0.00000 

0.00320 

■Q 

15 

1 

0.00000 

0.00320 

0.00120 

0.00440 

11 

7 

0 

0.00000 

0.00128 

0.00000 

0.00128 

11 

10 

1 

0.00050 

0.00168 

0.00048 

0.00216 

11 

15 

0 

0.00000 

0.00320 

0.00000 

0.00320 

11 

IBS 

1 

0.00000 

0.00320 

0.00120 

0.00440 

mm 

8 

0 

0.00000 

0.00320 

0.00000 

0.00320 

ms 

8 

1 

0.00000 

0.00320 

0.00120 

0.00440 

ms 

9 

0 

0.00000 

0.00320 

0.00000 

0.00320 

ms 

9 

1 

0.00000 

0.00320 

0.00120 

0.00440 

mn 

10 

0 

0.00000 

0.00320 

0.00000 

0.00320 

ms 

10 

1 

0.00000 

0.00320 

0.00120 

0.00440 

ms 

11 

0 

0.00000 

0.00320 

0.00000 

0.00320 

116^ 

11 

2000000| 

1 

0.00000 

Kmm i 
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Table  14.  Calculation  of  High-High  Scenario  Total  Cost  Per  Packet 


0.8  Delay  Sensitivity  This  table  is  used  to  calculate  costs  using  the  routes  from  Dijkstra's  All-Pairs  algorithm. 

0.8  Detectibility  These  costs  are  used  to  calculate  better  (lower  cost)  routes  based  on  context. 

1000  Packet  Size  (bytes)  _ _ _ _ _ 


From 

Node 

To 

Node 

Bandwidth 

(bps) 

Detectible 
0  =  No 

1  =  Yes 

Propagation 

+ 

Queue  Delay 
(sec) 

Delay 

Sensitivity 

Cost 

Detectibility 

Cost 

Total  Cost 
Per 
Packet 

0 

1 

0 

0.12370 

1 

0 

0 

0.12370 

0.09896 

0.00000 

0.09896 

1 

2 

BMiIOIiIiIiItliliJ 

0 

0.00540 

0.00432 

0.00000 

0.00432 

1 

3 

0 

0.11830 

0.09464 

0.00000 

0.09464 

1 

4 

0 

0.11830 

0.09464 

0.00000 

0.09464 

2 

1 

0 

0.00540 

0.00432 

0.00000 

0.00432 

2 

4 

0 

0.11830 

0.09464 

0.00000 

0.09464 

2 

5 

0 

0.11830 

0.09464 

0.00000 

0.09464 

3 

1 

0 

0.11830 

0.09464 

0.00000 

0.09464 

3 

4 

0 

0.00160 

0.00128 

0.00000 

0.00128 

3 

6 

■MMiMiIiIiIi] 

0 

0.00160 

0.00129 

0.00000 

0.00129 

4 

1 

0 

0.11830 

0.09464 

0.00000 

0.09464 

4 

2 

0 

0.11830 

0.09464 

0.00000 

0.09464 

4 

3 

imummmi 

0 

0.00160 

0.00128 

0.00000 

0.00128 

4 

5 

nnmmmoi 

0 

0.00160 

0.00128 

0.00000 

0.00128 

4 

6 

■t.l.I.I.I.I.W.1.1 

0 

0.00160 

0.00129 

0.00000 

0.00129 

4 

7 

■MiIiIiIiIiIiMiI 

0 

0.00160 

0.00129 

0.00000 

0.00129 

5 

2 

0 

0.11830 

0.09464 

0.00000 

0.09464 

5 

4 

BIiIiIiMiIiIOIiIiJ 

0 

0.00160 

0.00128 

0.00000 

0.00128 

5 

7 

■IiIiMiMiMiIi] 

0 

0.00160 

0.00129 

0.00000 

0.00129 

6 

3 

0 

0.00160 

0.00129 

0.00000 

0.00129 

6 

4 

■I.I.W.W.M.M 

0 

0.00160 

0.00129 

0.00000 

0.00129 

6 

7 

mumma 

1 

0.00110 

EgaSl 

■■HiMil.feM 

■millliiM 

6 

8 

1 

0.00000 

0.00128 

0.00128 

0.00256 

6 

9 

0 

0.00000 

0.00128 

0.00000 

0.00128 

7 

4 

mmwfflffli 

0 

0.00160 

0.00129 

0.00000 

0.00129 

7 

5 

■IiIiMiIiMiIiM 

0 

0.00160 

0.00129 

0.00000 

0.00129 

7 

6 

■MI.M.M.M 

1 

0.00110 

EHH 

7 

10 

1 

0.00000 

0.00128 

0.00128 

0.00256 

7 

11 

0 

0.00000 

0.00128 

0.00000 

0.00128 

8 

6 

1 

0.00000 

0.00128 

0.00128 

0.00256 

8 

9 

1 

0.00050 

0.00168 

0.00128 

0.00296 

8 

12 

0 

0.00000 

0.00320 

0.00000 

0.00320 

8 

13 

1 

0.00000 

0.00320 

0.00320 

0.00640 

9 

6 

0 

0.00000 

0.00128 

0.00000 

0.00128 

9 

8 

1 

0.00050 

0.00168 

0.00128 

0.00296 

9 

10 

1 

0.00050 

0.00168 

0.00128 

0.00296 

9 

§KE3 

0 

0.00000 

0.00320 

0.00000 

0.00320 

9 

14 

1 

0.00000 

0.00320 

0.00320 

0.00640 

H 

7 

1 

0.00000 

0.00128 

0.00128 

0.00256 

H 

9 

1 

0.00050 

0.00168 

0.00128 

0.00296 

HI 

11 

1 

0.00050 

0.00168 

0.00128 

0.00296 

BUS 

14 

0 

0.00000 

0.00320 

0.00000 

0.00320 

■Q 

15 

1 

0.00000 

0.00320 

0.00320 

0.00640 

11 

7 

0 

0.00000 

0.00128 

0.00000 

0.00128 

11 

10 

1 

0.00050 

0.00168 

0.00128 

0.00296 

11 

15 

0 

0.00000 

0.00320 

0.00000 

0.00320 

11 

IBS 

1 

0.00000 

0.00320 

0.00320 

0.00640 

mm 

8 

0 

0.00000 

0.00320 

0.00000 

0.00320 

ms 

8 

1 

0.00000 

0.00320 

0.00320 

0.00640 

ms 

9 

0 

0.00000 

0.00320 

0.00000 

0.00320 

ms 

9 

1 

0.00000 

0.00320 

0.00320 

0.00640 

mn 

10 

0 

0.00000 

0.00320 

0.00000 

0.00320 

ms 

10 

1 

0.00000 

0.00320 

0.00320 

0.00640 

ms 

11 

0 

0.00000 

0.00320 

0.00000 

0.00320 

116^ 

11 

2000000| 

1 

0.00000 

0.00320 

0.00320 

■JiliWM 
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Link  Costs  (High-Low) 


Figure  11.  High-Low  Scenario  Link  Costs 


Context-based  Routing  (Low-High) 
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Figure  13.  Low-High  Scenario  Context-Based  Routing  Table 
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Figure  14.  High-Low  Scenario  Context-Based  Routing  Table 
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Context-based  Routing  (High-High) 
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Figure  15.  High-High  Scenario  Context-Based  Routing  Table 
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Table  15.  Calculation  of  Baseline  Scenario  Bandwidth 
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Low- Low 

Time  Bandwidth 

(sec)  bwlO.tr  bwll.tr  bwl2.tr  bwl3.tr  bwl4.tr  bwl5.tr  bwl6.tr  bwl7.tr  bwl8.tr  (Mbits/sec) 


0 


0 
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Bandwidth  Comparison  (Dijkstra  vs  Low-High) 
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Figure  16.  Bandwidth  (Dijkstra  vs  Low-High) 
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Bandwidth  Comparison  (Dijkstra  vs  High-Low) 
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Figure  17.  Bandwidth  (Dijkstra  vs  High-Low) 
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Bandwidth  Comparison  (Dijkstra  vs  High-High) 
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Figure  18.  Bandwidth  (Dijkstra  vs  High-High) 
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